The Exchange Server 2010 Deployment Process

Note:

It is always important to follow good change management practice when deploying Exchange Server.

Each version of Exchange Server since Exchange 2000 Server has been reliant on Active Directory Domain Services (AD DS) to function. All of the user accounts, mailboxes, distribution groups, and the configuration for the services are stored within AD DS. Anytime information is needed about a mail-enabled object or configuration information is needed for any of the Exchange services, AD DS must be queried. If AD DS is not available, Exchange will fail to work properly. To better understand how tightly Exchange integrates with AD DS and to underscore the importance of properly configuring and preparing AD DS for deployment, it is good to understand the basics.

1. Exchange and Active Directory Domain Services

1.1. The Configuration Partition

The configuration partition contains information about the configuration of the entire Exchange organization. The same configuration partition is replicated to all of the domain controllers in an AD DS forest. The Exchange configuration is stored within a container in the Services container, as shown in Figure 1.

A number of Exchange configuration objects are stored in this container, including:

• Address lists

• Address policies

• Client access settings

• Messaging records management, mobile, and UM mailbox policies

• Federation settings

• Global settings

• System policies

• Transport settings

Although the Exchange configuration is stored in the configuration container, you should never adjust settings directly unless specifically directed to by Microsoft support personnel. You should always use the Exchange management tools such as the Exchange Management Console or Exchange Management Shell to make any configuration settings.

1.2. The Schema Partition

The schema partition stores classes and attributes. Classes are the types of objects that can be created in AD DS and attributes are properties for these objects. The schema partition can be likened to a recipe book, which describes the ingredients and processes that should be followed to make a dish. This is just how the schema defines the objects that are created in the other AD DS partitions. Just as it would seem absurd to eat the recipe book, the schema partition only defines the objects but does not actually store those objects. Unlike other partitions, the schema partition is not multi-master. A single domain controller in the forest acts as a schema master and is the only domain controller with a writeable copy of the schema.

The Exchange installation extends the schema by adding many classes and attributes into it, including mail-enabled users, mail-enabled groups, databases, servers, and connectors. Each of these classes has a number of properties that are used to describe the objects. When a mailbox object is created in domain partition, as seen in Figure 2, a number of attributes can be seen using ADSI Edit. These attributes include homeMDB, e-mail address, RBAC role assignment, and a number of others.

1.3. The Domain Partition

Each domain in a forest has a domain partition. The domain partition is only replicated to the domain controllers that are members of that domain. The domain partition contains information about users, computers, and groups. When users, mailboxes, and distribution groups are created in AD DS they are stored in a domain partition using the class and attributes defined in the schema partition.

1.4. How Exchange Uses Active Directory

Each of the Exchange server roles is dependent on the Active Directory Topology service, which is the service that gathers information from each of the Active Directory partitions. As mentioned previously, data about the Active Directory site, where domain controllers and global catalog servers are located, as well as information about the other Exchange servers in the organization is read and cached from Active Directory. When the Active Directory Topology service starts, it binds itself to a random domain controller and global catalog server in the local Active Directory site. After binding and retrieving information from any of the local writeable domain controllers, the service continually evaluates the performance of each Active Directory server in the site to ensure that all available servers are identified and to remove any servers that are no longer suitable for use. A static list of domain controllers can be specified for each Exchange Server computer to use; however, because of the dynamic nature of AD DS you should allow Exchange to build this list dynamically to ensure that all available domain controllers are used. Many organizations with larger Exchange deployments may choose to put the Exchange Server computers in a separate site with dedicated domain controllers so as to segregate any desktop user authentication from any Exchange-related lookups, which could resource completion servicing Exchange and desktop requests. The following list shows how each Exchange role relies on AD DS to function.

Note:

Although Exchange 2010 can be deployed in a site with read-only domain controllers, these servers are ignored for use by Exchange. At least one writeable global catalog server is required in each Active Directory site that hosts an Exchange 2010 computer. Two or more writeable domain controllers are recommended for redundancy.

• Client Access Server Role Users connecting to the Client Access Server via: MAPI, Outlook Web App, Exchange Web Services, Exchange Control Panel, Post Office Protocol version 3 (POP3), Internet Message Access Protocol Version 4rev1 (IMAP4), or Microsoft Exchange ActiveSync. AD DS is used to authenticate the user and to determine the user's mailbox database. If the mailbox is located in another directory the connection may be redirected.

• Edge Transport Server Role The Edge Transport servers are not to be members of one of domains in the Exchange forest; each Edge Transport server employs a local, lightweight version of an AD DS database within Active Directory Lightweight Directory Services (AD LDS), which stores configuration information for each Edge Transport server. The Edge Transport server retrieves configuration information including recipient lookup and safe list aggregation through an edge subscription to an Active Directory site. The Hub Transport servers in a subscribed site use the Microsoft Exchange EdgeSync service to synchronize AD DS information into the AD LDS instance on each Edge Transport server.

• Hub Transport Server Role The Hub Transport server role queries AD DS when it performs recipient lookup and routing resolution during message categorization. The categorizer also retrieves information about the recipient's mailbox such as the, restrictions, and permissions that apply. The categorizer must also query AD DS to obtain the members and restrictions for distribution lists. To calculate routing information, the categorizer uses the information that is retrieved and cached by the Active Directory Topology service.

• Mailbox Server Role The Mailbox server role uses information about mailboxes, agents, global settings, and address lists in AD DS.

• Unified Messaging Server Role The Unified Messaging servers query AD DS for configuration information such as dial plans, hunt groups, and gateways. The UM servers also use AD DS to match a destination telephone number to a recipient address to submit the message to a Hub Transport server in the local Active Directory site.